Method for storing multiple levels of design data in a common database

ABSTRACT

An automated logic circuit design system uses a common database to store design data at different states of the design process, including data-flow graphs, netlists and layout descriptions. In this way, the need to translate circuit descriptions between tools is eliminated, thus leading to increased speed, flexibility and integration. The common database includes entities, models, cells, pins, busses and nets. The data-flow graphs are stored as graphs, the nodes in a graph as cells, and the edges as busses. Physical design data is available by storing the cells in a model in a KD tree. This allows queries on cells in the netlist located in the layout within arbitrary areas.

CLAIM OF PRIORITY

This is a continuation of U.S. application Ser. No. 10/159,531 filed May31, 2002, which is a divisional of U.S. application Ser. No. 09/300,540filed Apr. 27, 1999, now U.S. Pat. No. 6,505,328 issued Jan. 7, 2003.

FIELD OF THE INVENTION

The present invention is directed to digital logic design systems. Moreparticularly, the invention is directed to automated digital logicsynthesis and placement systems.

BACKGROUND OF THE RELATED ART

Prior art computer aided design (CAD) systems for the design ofintegrated circuits and the like assist in the design thereof byproviding a user with a set of software tools running on a computer. Inthe prior art, the process of designing an integrated circuit on atypical CAD system was done in several discrete steps using differentsoftware tools.

First, a schematic diagram of the integrated circuit is enteredinteractively to produce a digital representation of the integratedcircuit elements and their interconnections. This representation mayinitially be in a hardware description language such as Verilog and thentranslated into a register transfer level (RTL) description in terms ofpre-designed functional blocks, such as memories and registers. This maytake the form of a data structure called a net list.

Next, a logic compiler receives the net list and, using a componentdatabase, puts all of the information necessary for layout, verificationand simulation into object files whose formats are optimizedspecifically for those functions.

Afterwards, a logic verifier checks the schematic for design errors,such as multiple outputs connected together, overloaded signal paths,etc., and generates error indications if any such design problems exist.In many cases, the IC designer improperly connected or improperly placeda physical item within one or more cells. In this case, these errors areflagged to the IC designer so that the layout cells may be fixed so thatthe layout cells perform their proper logical operation. Also, theverification process checks the hand-laid-out cells to determine if aplurality of design rules have been observed. Design rules are providedto integrated circuit designers to ensure that a part can bemanufactured with greater yield. Most design rules include hundreds ofparameters and, for example, include pitch between metal lines, spacingbetween diffusion regions in the substrate, sizes of conductive regionsto ensure proper contacting without electrical short circuiting, minimumwidths of conductive regions, pad sizes, and the like. If a design ruleviolation is identified, this violation is flagged to the IC designer sothat the IC designer can properly correct the cells so that the cellsare in accordance with the design rules.

Then, using a simulator the user of the CAD system prepares a list ofvectors representing real input values to be applied to the simulationmodel of the integrated circuit. This representation is translated intoa form which is best suited to simulation. This representation of theintegrated circuit is then operated upon by the simulator which producesnumerical outputs analogous to the response of a real circuit with thesame inputs applied. By viewing the simulation results, the user maythen determine if the represented circuit will perform correctly when itis constructed. If not, he or she may re-edit the schematic of theintegrated circuit, re-compile and re-simulate. This process isperformed iteratively until the user is satisfied that the design of theintegrated circuit is correct.

Then, the human IC designer presents as input to a logic synthesis toola cell library and a behavioral model. The behavioral circuit model istypically a file in memory which looks very similar to a computerprogram. The behavioral circuit model contains instructions which definelogically the operation of the integrated circuit. The logic synthesistool receives as input the instructions from the RTL circuit model(i.e., Verilog or VHDL) and the library cells from the library. Thesynthesis tool maps the instructions from the behavioral circuit modelto one or more logic cells from the library to transform the behavioralcircuit model to a gate schematic net list of interconnected cells. Agate schematic net list is a data base having interconnected logic cellswhich perform a logical function in accordance with the behavioralcircuit model instructions. Once the gate schematic net list is formed,it is provided to a place and route tool.

The place and route tool is used to access the gate schematic net listand the library cells to position the cells of the gate schematic netlist in a two-dimensional format within a surface area of an integratedcircuit die perimeter. The output of the place and route step is atwo-dimensional physical design file which indicates the layoutinterconnection and two-dimensional IC physical arrangements of allgates/cells within the gate schematic net list.

According to the above prior art method, a separate internal datastructure is used for each tool. This is because the tools are rarely ifever written by the same group; thus, the internal databaserepresentation for each tools is likely to differ from that of the othertools. Also, the most appropriate database implementation for theintegrated circuit depends on the phase of the design process in whichit is being used. For example, linked lists are commonly used to storecells in a netlist because that is the most obvious solution for logicsynthesis purposes. In contrast, a KD tree is a more appropriatedatabase format for the place and route tool.

This is time-consuming and processor-intensive (circuit specificationsmust be translated from one database format to another and anotherduring the development process), disk-intensive (multiple databases eachspecifying the same circuit in different forms must be stored) andfragmented (tools cannot use the outputs of other tools, and a change tothe circuit made by one tool is not reflected in the databases of theother tools).

SUMMARY OF THE INVENTION

The present invention has been made with the above problems of the priorart in mind, and a first object of the present invention is to provide asystem for automated logic circuit design which is capable of storingand utilizing multiple levels of design data in a common database.

Another object of the present invention is to provide a system forautomated logic circuit design which eliminates the need for translationof circuit descriptions between different design tools.

A further object of the present invention is to provide a system forautomated logic circuit design which allows the output of tools in thedesign suite to be used by other tools.

Yet another object of the present invention is to provide a system forautomated logic circuit design which allows design tools or the user tomake area queries, i.e., a selection of a subset of objects based ontheir physical position, at various stages in the design process.

A still further object of the present invention is to provide a systemfor automated logic circuit design which permits the use of globalsimulation tools such as timing engines across all levels of designabstraction.

Another object of the present invention is to provide a system forautomated logic circuit design which presents a unified model fortiming, synthesis, placement and routing.

A further object of the present invention is to provide a system forautomated logic circuit design which has high storage and run-timeefficiency.

A still further object of the present invention is to provide a systemfor automated logic circuit design which has a consistent and easy touse programming interface.

A still further object of the present invention is to provide a systemfor automated logic circuit design which has an interface which is notdependent on other include files.

A further object of the present invention is to provide a system forautomated logic circuit design which uses an object-oriented C++programming style.

The above objects are achieved according to an aspect of the inventionby providing an automated logic circuit design system which uses acommon database to store design data at different states of the designprocess, including data-flow graphs, netlists and layout descriptions.In this way, the need to translate circuit descriptions between tools iseliminated, thus leading to increased speed, flexibility andintegration. The common database includes entities, models, cells, pins,busses and nets. The data-flow graphs are stored as graphs, the nodes ina graph as cells, and the edges as busses. Physical design data isavailable by storing the cells in a model in a KD tree. This allowsqueries on cells in the netlist located in the layout within arbitraryareas.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other objects, features, and advantages of the presentinvention are better understood by reading the following detaileddescription of the preferred embodiment, taken in conjunction with theaccompanying drawings, in which:

FIGS. 1-3 are dataflow diagrams of a circuit structure according to apreferred embodiment of the present invention;

FIG. 4 is a block diagram of the structure of a data model according tothe present invention; and

FIG. 5 is a diagram of the partitioning of a chip in correspondence withthe data model.

DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EXEMPLARY EMBODIMENT

First, given a Verilog description of a circuit to be developed, theVerilog must be parsed to generate a data flow graph suitable forimplementation in the data model. RTL parsers known in the art arepreferably used for this purpose. The output from the RTL parser is aVerilog parse tree which is used to generate the data flow graph.Although well-known in the art, the structure of the parse tree isrelatively complicated and, since detailed knowledge of it is notnecessary for an understanding of the present invention, furtherdescription of the parse tree will be omitted for simplicity andbrevity.

FIG. 1 shows an example of translation of the Verilog source code always@(posedge clk) begin out = in1 + in2; if (c) out = in3; end

into data flow elements. Here, in0, in1, in2, c and clk are input portsof an Entity (described below) and out is an output port of the Entity.An adder (an example of a Cell as described bellow) adds the values atPorts in0 and in1 and supplies the result to a merge block (anotherexample of a Cell). If the value at Port c represents a logical true,the merge block supplies the value at Port in2 to a delay block (again,a Cell); if the value at Port c represents a logical false, the mergeblock supplies the output of the adder to the delay block. On thepositive-going edge of the signal at Port clk, the delay block providesthe value on its input to the output port out. The data flow graphhaving been generated, it may then be stored in the data model.

Before describing the data model in more detail, a few more examples arein order. FIG. 2 shows an example of the data graph resulting from theVerilog code if (c1) begin out = in0; end else begin if (c2) begin out =in1 end else begin out = in2 end end

Here, if the value at input Port c1 is a logical true, the branch moduleconnected to input Port in0 is enabled and provides its output to amerge module which is also enabled when c1 is true. If c1 is not true,the branch modules connected to Ports in1 and in2 are enabled to providetheir outputs to other branch modules. One of the modules in this secondtier is enabled when the value at input Port c2 is true and provides itsoutput to another merge block. The other of the modules in the secondtier is enabled when c2 is false and provides its output to the othermerge block. Depending on the value of c2, one of those outputs isprovided to the first merge block, and depending on the value of c1, oneof the output is provided to the output port out via the delay element.

Finally, repetitive structures such as for, while and forever loops canbe implemented in the data flow graph. FIG. 3 shows an example of thedata flow graph implementation of the Verilog code integer i; for (i=0;i<5; i++) begin a = a−4 end

Here, an entry node initializes a loop index with the value 0, adds 1 tothe index and checks to see if the index is less than 5. If so, an exitnode loops back for another pass. In tandem with this loop, an inputvariable a is received through another entry node and 4 is subtractedfrom it on each pass through the loop. When looping ceases because theindex has reached 5, the current value of the input variable ispresented at the exit node.

Certain optimizations can be performed on the data flow graph. Forexample, in the above loop structure the loop can be unrolled. That is,the graph portion representing the body of the loop can be replicatedfive times and the graph portion representing the loop index can beeliminated. For timing estimations and the like, virtual loop unrollingcan be performed by estimating the number of iterations through the loopand using that number as a multiplier in delay calculations; the actualcircuit replications can be done later.

Once the Verilog source is converted to a data flow graph, it can beimplemented in the data model. Preferably, the data model is implementedusing the C++ programming language or a similar object-orientedlanguage. Since the construction, accessing and destruction of objectsin such languages is well-known in the art, examples of specificcommands for performing these operations will be omitted for brevity.

The topmost object in the data model 10 (shown in FIG. 4) is the Rootobject 20. The Root object 20 owns all other objects 30-70 and serves asa base to which everything else is attached. Also, the root 20accommodates global attributes which are shared by all objects 20-70.

At the next level of the data model 10 is the Library object 30. Libraryobjects 30 are used to organize entities 40. The preferred embodiment ofthe present invention includes at least two Libraries 30. The firststores information on the technology library to which the circuit underdevelopment will be mapped, and the second stores information on thecircuit itself.

Next is the Entity object 40. An Entity 40 defines the interface of adesign; that is, the set of ports 52 that the Entity 40 has. An Entity40 may own Port objects 52. A Port 52 is used to represent the pin-outof an entity 40. Ports 52 cannot be individually created and destroyed,and can only be created when an Entity 40 is created. Each Port 52 has adirection (in, out, in/out) which is determined upon creation of theEntity 40. This rigidity promotes consistency between the Entity 40, itsModels 50 and the Cells 62 bound to those Models 50.

As noted above, Entities 40 own Models 50. A Model 50 defines animplementation of an Entity 40; thus, multiple Models 50 within anEntity 40 represent different implementations of that Entity 40.Generally, these Models 50 are functionally identical to one another.For example, an Entity 40 in a technology Library 30 may have severalModels 50 defining various eight bit adder cells having different powerlevels. Similarly, an Entity 40 in a target Library 30 may have severalModels 50 which respectively define an abstract logic representation ofa circuit, a gate-level implementation of it, a uniquefiedrepresentation, etc. The contents of each Model 50 is a net list of Nets60, Cells 62 and Model Pins 64. All Models 50 and the Entity 40 have thesame number of Pins 64 and Ports 52, and the Ports 52 have the samedirection in the Entity 40 and over all Models 50; thus, it isrelatively easy to replace one Model 50 with another from the sameEntity 40.

Below the Models 50 are Cell objects 62. A Cell 62 represents a sectionof logic. Cells 62 may be primitive cells or non-primitive cells.Primitive Cells 62 have a predefined functionality associated with them.Preferably, the primitive Cells 62 include the following types:

CELL_AND—unlimited fan-in AND gate;

CELL_XOR—unlimited fan-in OR gate;

CELL_TRI—tri-state buffer

CELL_REG—sequential element

CELL_DC—don't care set

CELL_BREAK—break point cell; used to implement a “don't touch”; and

CELL_ONE—a constant one; an inverted or bubbled version is used for aconstant zero.

In contrast to primitive Cells, the functionality of non-primitive Cellsis defined by technology Models 50 to which they are bound. That is, aCell 62 may describe a portion of the circuit under development andbelong to a Model 50 in a target Library 30. However, it will beassociated with (preferably by pointing through a cell type attribute orthe like) a Model 50 in a technology library 30 which defines itsfunctionality and general characteristics.

Non-primitive Cells 62 may be created as bound Cells; alternatively,they may be created as unbound Cells and later bound to a Model 50. Thismay be done by specifying the Cell's name; by specifying pin-to-pincorrespondence vectors; and by binding the Cell 62 to an undefined Model50 and later matching the Model 50 to an actual one. Additionally, abound Cell 62 can be rebound to a different Model 50 within the sameEntity 40.

Each Cell 62 includes a number of parameters called members whichspecify certain features of the Cell 62. These include the cell's name,a pointer to the technology Model 50 to which it is bound, a list ofPins 64 which it owns, its parent Entity 40, and coordinates of the Cell62 within the chip layout.

Net objects 60 make connections between pins. The pins may be Model pins64 or Cell pins 70. A Net 60 does not own Pins 64 and 70, and deletingthe Net 60 will leave the pins 64 and 70 disconnected. Pins 64 and 70may be grouped into Busses 80 (in fact, every variable in the Verilogcode will be represented as a Bus). Since Pins 64 and 70 are the mostcommon object in almost any circuit representation, it is important toreduce the amount of storage for each Pin 64 and 70 as much as possiblewhile maintaining easy accessibility. For this reason, Pins 64 and 70are preferably stored in small arrays and associated with indices.

Nets 60 also have members, such as the Net's name, a list of Pins 64 and70 which it connects, and a list of rectangles through which it passesin the placement layout. Pin members include the Pin's name, the Model50 or Cell 62 to which it belongs, and the Net 60 to which it isconnected.

Each object 20-70 may have a number of attributes. Each attribute has aname and a value of a type int, short, float, double, char* and void*.One example of an object attribute is an inversion attribute or “bubble”which specifies whether a Cell input or output (or Net 60) is assertedhigh or low. Other examples of object attributes are object name, firinginformation, references to the Verilog code defining the object, etc.

Iterators are procedures used to access objects within the data model.As is known in the art, an iterator traverses the model and each time itis called, returns a pointer to the next object of a particular type.For example, a Model iterator would, when successively called, returnpointers to each Model 50 within the data model. The preferredembodiment of the present invention provides “safe” and “unsafe”iterators, where unsafe iterators return all objects of the specifiedtype, even if they have been added during the iteration process, andsafe iterators omit objects added during the iteration. In this way,although the safe iterators are slightly slower than their unsafecounterparts, they can avoid program crashes, errors and exceptions, andother undesirable outcomes.

Before synthesis and timing can take place it is often necessary touniquefy the data model. This involves binding each Cell 62 to its ownindividual technology Model 50. This simplifies the synthesis process inthat changes made to one technology Model 50 will affect only the Cell62 which is bound to it, and no others. Also, after uniquefication it ispossible to traverse the data model both up and down, since each objecthas a unique parent and child. Typically, uniquefication is done bymaking a copy of a technology Model 50 for each Cell 62 which is boundto it and associating one of the cells 62 to each copy.

After the data model has been uniquefied, it may be ungrouped, i.e.,macro-level cells can be replaced with their primitive components.Alternatively, processes may handle the data model with virtualungrouping by “looking through” the macro-level cells to process theirprimitive cell constituents.

With this understanding of the structure of the data model in mind,implementation of a Verilog-derived data flow graph in the data modelwill now be described. For each module in the Verilog description therewill be one Entity 40 and one Model 50 (hereinafter collectivelyreferred to as a graph). The ports for the Entity 40 correspond to theports in the Verilog module. Ports 52 in the graph have a bit width, andthere will be a separate Pin 64 and Net 60 (the group of Nets 60 for thePort 52 forming a Bus) in the graph for each Verilog port.

For each node in the Verilog module, a Cell 62 will be made in thegraph. Initially the Cells 62 will be unbound. As described above, giventhe Cell type and the Pins 70 of the Cell 62, a Model 50 for the Cell 62to be bound can be generated later.

Each Model 50 is preferably implemented as a KD tree as follows. First,the circuit under development is divided into a number of sections eachcorresponding to a rectangular section 100 of the available chip area asshown in FIG. 5. The partitioning of the circuit can be directed by theuser; however, it is preferably automatically done by the system so thatthe circuit is evenly distributed over the entire chip area. Each nodeor leaf 210 of the KD tree 200 shown in FIG. 6 corresponds to a cutline110 of the rectangles 100 and may have appended thereto a linked list220 of all cells 62 which lie on that cutline 110. Non-leaf nodes 210 inthe KD tree 200 each have two child nodes 210, with the left child 210corresponding to the region of the chip on one side of the cutline 110and the right child 210 corresponding to the region of the chip on theother side of the cutline 110. Similarly, the child nodes 210 may havelinked lists 220 of cells on their cutlines 110 and child nodes 210 oftheir own.

It should be noted that the leaf nodes 210 will contain most of thecircuit information, since the non-leaf nodes 210 will only haveinformation on those cells touching their corresponding cutline.

As noted above, the initial distribution of Cells 62 over the chip areais preferably done automatically by the system and in that case may bedone through the use of various algorithms which will readily suggestthemselves to those skilled in the art. The result of this process is amodel with mostly logical information on its constituent elements butwith a coarse framework of physical placement and routing information,e.g., cell areas, initial placements, etc. In later steps of thedevelopment process described below, the physical information will berefined and augmented within the original data model. In this way, theaddition of rough physical layout information to the initial logicaldescription enables the smooth transition of the circuit through thedevelopment process, thereby enabling sharing of tool outputs, use ofcommon diagnostics and the like.

Further, once RTL synthesis is complete and the data model is flattened,it may be copied and used as a baseline for formal verification and thelike. Since a common model structure is used, there is no need totranslate the pre-logic synthesis version of the circuit into a formatsuitable for use by the verification tool.

As the development process progresses, the KD tree 200 may becomeunbalanced due to an excessive number of additions or deletions in onearea, or due to poor initial distribution. This can be compensated forby manual rebalancing by the user or by a user-initiated procedure, butpreferably is done automatically by the system.

Once the data model has been constructed in this way, it may be used forboth logic synthesis, i.e., gate-level implementation, etc., andphysical synthesis, i.e., placing and routing. This is because the datamodel includes all of the information necessary for logical synthesisoperations, i.e., cell functionality, net connections, etc., as well asall information necessary for physical synthesis operations, i.e.,areas, physical positions, etc.

Another advantage of the data model arises from its correspondence withthe actual physical chip layout. Since each node of the KD tree 200corresponds to a cutline 110 and has associated with it the cells on thecutline and information on where its child nodes are within the chiparea, portions of the circuit in specific physical areas can be queried,tested and manipulated without the need to read the entire data modelinto active memory from disk storage, as is the case with prior art netlists. For example, assuming a user wanted to work with only the lowerright hand corner of the chip, the system could traverse the KD tree toreach the topmost node corresponding to that area. Then, that node, itschildren, netlists and the like would be read into active memory fromdisk and manipulated. The user may even be able to manually directplacement of cutlines 110 at certain points to frame a particular areaof interest. The system may then adjust the KD tree accordingly toaccommodate the new arrangement. This area query technique is possiblewhether the circuit is in its final placement and routing stages orfresh from Verilog synthesis.

Although only a portion of the entire data model need be read intomemory, the complete set of Nets 60 is typically maintained in memory.This is because the Nets 60 are necessary for purposes such as delayestimation and the like that are performed frequently, and it is easierto retain all Nets 60 in memory rather than repeatedly read them intomemory. Thus, once a specific area has been designated for querying, theNets 60 corresponding to that area must be identified. This is done byidentifying the Nets 60 connected to each of the Pins 64, 70 within theselected area. The remaining Nets 60 can be eliminated fromconsideration during the area query. Nets 60 which have some, but notall, Pins 64, 70 within the query area can have the missing pinsrepresented by a stub pin. Finally, Nets 60 which have all of their pinswithin the query area can be handled as are other objects within theselected area.

Further, during the area query process, Nets 60 which are entirelycontained within the selected area can be optimized out or otherwisemodified; however those nets having portions outside the query area,i.e., those with stub pins, cannot, since the effect of modification ofelimination of these Nets 60 on the remaining circuit portions isunpredictable.

Further, since the logical and physical aspects of the circuit areintegrated into a single data model from the start, deviations from theclassic logical synthesis/physical synthesis partition can be made. Forexample, the inclusion of buffers for load handling and timing purposesis normally done as part of the logical synthesis process; however,using a common data model for all aspects of the development processallows the placement of buffers to be delayed until later during theplacement process, when layout information is more definite and precise.

The above description of the preferred embodiment of the presentinvention has been given for purposes of illustration only, andvariations thereof will be readily apparent to those skilled in the art.For example, although Verilog has been used as the preferred languagefor initial input of the circuit under development, other appropriatehardware description languages may of course be used. Also, althoughimplementation of the data model using object-oriented C++ techniqueshas been disclosed, other programming languages and paradigms may alsobe workable. Similarly, alternative object hierarchies may be used. Suchvariations fall within the scope of the present invention. Thus, thescope of the present invention should be limited only by the appendedclaims.

1. A method of storing data for use by an automated logic circuit designsystem comprising the steps of: providing a common database that allowsfor storage of data associated with automated circuit design; performingat least one logical operation and at least one physical operation, witheach operation accessing the common database and modifying the datatherein, the at least one logical operation including at least one oflogic synthesis and timing simulation operations and the at least onephysical operation including at least one of physical placement andphysical routing operations; and wherein each of the logic synthesis,timing simulation, physical placement, and physical routing operationsare performed and each operation accesses the common database andmodifies the data stored therein.
 2. The method according to claim 1further including the steps of making at least one area query.
 3. Themethod according to claim 2 wherein the step of making at least one areaquery makes a plurality of area queries, with one of the plurality ofarea queries taking place after the logical operation and another one ofthe plurality of area queries taking place during the at least onephysical operation.
 4. The method according to claim 2, wherein at leastone of the area queries is made to verify a property of the circuit. 5.The method according to claim 4 wherein the property is a spacingbetween adjacent nets.
 6. The method according to claim 5 wherein thespacing is used in order to simulate a timing of the circuit.
 7. Themethod according to claim 4 wherein the property is adherence to designrules.
 8. The method according to claim 7 wherein the design rulerelates to spacing between diffusion regions in the substrate.
 9. Themethod according to claim 7 wherein the design rule relates to pitchbetween metal lines.
 10. The method according to claim 7 wherein thedesign rule relates to minimum widths of conductive regions.
 11. Themethod according to claim 2 wherein the at least one area query is madewhen performing diagnostics.
 12. The method according to claim 11wherein the diagnostics include checking for electrical shortcircuiting.
 13. The method according to claim 2 wherein the at least onearea query is made to manipulate a portion of the circuit.
 14. Themethod according to claim 13 wherein the manipulating of the portion ofthe circuit adds a buffer to the portion of the circuit to obtain propertiming for that portion of the circuit.